Subject: DCL Comments on ATM-05

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Wed, 10 Jul 96 11:59:16 EDT

Matthew, thanks for your comments and thorough review.

Below find my responses, but first a caveat.  Many of your comments deal
with the node functional decomposition model and intranode flows.
I have attempted in the HPR/ATM design to include a reasonable model that
could be implemented, and I welcome comments on this aspect of the design
and am willing make improvements; however, these are areas for product
implementation choices.

>We've read the new HPR over ATM specification.  Overall we think it
>looks to be in very good shape - well done.
>
>Looking at its contents in the light of the requirements for CP it looks
>like it's pretty well all there.  The only particular omission we've
>noticed is that there are no code size estimates included.  Is this
>deliberate?

As an architect, I don't deal with code very often and must rely on
others to provide code sizings.  No IBM product has stepped forward
to provide an estimate.  You are familiar with the architecture and
code; would it be possible for you to provide an estimate?

My understanding of the AIW procedures is that rough code sizings are
suggested at AD time so that the AIW can determine if it wants to
proceed with an architectural design effort.  Estimates tend to be
unreliable because they are so platform dependent (especially when
dealing with layer 2 code).  If you're unable to provide an estimate,
I think it's ok for us leave sizings out of the document.

>We do have a few comments on the document.  Firstly some technical
>issues which ideally should be addressed before CP.
>
> - Page 2-31
>The text reads that "at this point CS is notified of the incoming call
>and creates an instance of LDLC".  This introduces a new protocol
>exchange across the CS/DLC interface and as the document does not
>attempt to address how this should be implemented and how it should
>behave in  error conditions, it may cause problems with
>interoperability.  For example, what should the behaviour be when the
>SVC goes down between LDLC being created and the first XID being
>received?

I agree; I wasn't satisfied with the figures in sections 2.7.1.1 and
2.7.1.1.1 and had already made some changes that I planned to present
to the HPR SIG at AIW11.  I had four goals in mind:

- Bring in line with LDLC protocol boundary
- Distinguish between the LDLC and ATM signaling component
- Show the RFC 1483 component
- Change the trigger for CONNECT_IN(RQ)

My proposal is to make SETUP and PCM_CALL_SETUP.ind the trigger for
CONNECT_IN(RQ).  I also propose that CONNECT_IN(RQ) trigger CS to
create LDLC.  The proposal gives CS a chance to participate in the
decision on whether to accept the call by sending a + or -
CONNECT_IN(RSP); this would trigger the ATM signaling component to
either send PCM_CALL_CONTROL.req accepting the call or
PCM_CALL_CLEAR.req rejecting the call.

Once LDLC is created, I believe it should respond to an INOP by sending
ALERT_MSU(RQ) to CS.  This is a small change to the FSM.

> - The document is ambiguous as to whether ATM is to be accessed by a
>switched or a SATF port.  Much of the document (Page 2-36, Page 2-58)
>suggests SATF.  Other places, particularly Page 2-27 suggests switched
>("Regular TGs defined on SVCs are switched connections between two nodes
>..").  Indeed this paragraph states that the limitation of one active
>link per switch port is being lifted due to ATM's requirements.  This
>should be made consistent.

You've raised a good question here.  The Port_Defined_Data (see page
9-208 of the architecture reference) does show port type as having
3 possible enumerated values:  nonswitched, switched, and SATF.
Nonswitched was meant for leased lines, switched for switched lines,
and SATF for LANs.  HPR/ATM has properties of all three, but none of them
is an exact fit in all situations.  For example, HPR/ATM supports PVCs
(leased), auto-activatable defined links (switched), and connection
networks (SATF).  My intention is that the port type parameter on
DEFINE_PORT(RQ) be set to SATF (see page 2-58), but regardless of the
value chosen for HPR/ATM, some implementation changes are going to be
required.  I will make some clarifications.

By the way,the statement on page 9-11 of the architecture reference
("Multiple simultaneous switched connections through a single port are
not supported by the model described in this book.") does not clearly
indicate if it applies only to switched ports, but I agree that it could
be read that way.

> - Page 2-62
>"There is no need for multiple regular TGs to share a VCC; why bother
>defining them?"  Isn't this making assumptions about the customers'
>requirements?  What would happen, for example if the link passed through
>a gateway (with a VCC up to the gateway, and other DLC types beyond) as
>in the case shown below, where NN1 has TGs to both NN2 and NN3 which
>could potentially be carried on the same shared VCC between NN1 and the
>gateway.
>
>              ATM                        Token Ring
>
>
>  +-----+                +--------------+         +-----+
>  |     |----TG A--------|              |--TG A---| NN2 |
>  | NN1 |                |ATM/TR gateway|         +-----+
>  |     |----TG B--------|              |--TG B-+
>  +-----+                +--------------+       | +-----+
>                                                +-| NN3 |
>                                                  +-----+

SAP multiplexing, as incorporated in ATM-04 and ATM-05, handles the case
you describe.  The statement to which you refer is not related to SAP
multiplexing; rather, it deals with sharing of a NOF-defined HPR link by
connection network traffic.  In that case there is only one link.
The section was written before we added SAP multiplexing, and, as a
result, incorrectly assumes a single link per VC.  I'll clarify.

>Secondly, there are also a number of more minor other areas where we
>think the document should be clarified or corrected.
>
> - Section 2.4.1 Page 2-8
>This says that the Liveness protocol is optional.  Perhaps it should
>make it clear (as it does later on) that it's only sending TEST(CMD)
>that is optional - it's base function to respond to them?

Agreed.

> - Section 2.7.1 Page 2-26
>"When a connection network is defined on the ATM network, at most one
>defined link station per adjacent node is required for CP-CP sessions."
> I'm not sure what this sentence is trying to say.

All it's saying is that the only architectural requirement for defined
TGs as opposed to CN TGs is to support CP-CP sessions.  And if CP-CP
sessions are desired between adjacent nodes, then one defined TG between
them is sufficient; parallel defined TGs are allowed for availability,
etc. but not required.  I'll try to clarify.

> - Figure 2-20, Page 2-31
>The sample flow here suggests that CONNECT_IN and XID are a single
>signal.  I believe that in the APPN Architecture Reference they are
>actually separate signals and that the XID is sent up after the
>CONNECT_IN positive response has been received.

You are correct; see Fig. S-16 on page S-26 of the architecture
reference.  In my proposal described above, CONNECT_IN(RQ) is now
triggered by SETUP rather than receiving XID.  As a result,
CONNECT_IN(RQ) and XID are separate flows.  In fact, CONNECT_IN(RQ)
is sent by the ATM signaling component, and XID is sent by LDLC.

> - Figure 2-20, Page 2-31
>This shows a successful CONNECT_IN.  It would be useful to include a
>flow with an unsuccessful CONNECT_IN (as in the case of CONNECT_OUT).

As indicated above, my proposal allows for this.  I wasn't planning
a separate figure, but the accompanying text will indicate how the
flow would change.

> - Figures 2-22 and 2-23, Page 2-32
>It's not clear to me what the difference in the PCM_CALL_CLEAR.ind
>received in each case actually is.  Perhaps this could be clarified?

The Cause value in the Cause IE for normal deactivation is 16 "normal
call clearing" (preferred) or 31 "normal, unspecified" for UNI 3.1.
For UNI 3.0, only Cause value 31 is used.  All other Cause values
indicate an error of some sort, either during setup procedures or after
successful activation.  Maybe, a footnote would help.

> - Figure 2-22, Page 2-32
>Typo - "REPORT_DISCONNEDT(RSP)"

Ok, I'll fix.

> - Page 2-37
>"This can be costly for the customer if the tariff structure includes
>charges based on the number of SVCs established."  I do not believe that
>the spec addresses this issue - this should be made clear.

Agreed, I'll clarify.

> - Footnote 11, Page 2-40
>This footnote is very difficult to understand without far more knowledge
>of ATM (and in particular UNI protocols) than the document provides.  It
>should probably me made clearer or removed.

I'll see if I can add clarity.  The observation is that experimental
parameters should be avoided in a replicated database because they may
not be supported by all parts of the network.

> - Page 2-56
>"and SM of the PLU would attempt to reinitiate the session".  This
>certainly doesn't always happen (although the PLU may retry session
>activation if it is trying to auto-activate sessions or in the case of
>some old style PLUs).  This sentence should be reworded to make this
>clearer.

Ok, I'll fix.

>- Page 2-59 - 2-60
>It's rather confusing to refer throughout this section to footnotes
>which were included 30 pages before.

I guess I can have multiple footnotes with the same wording.

> - Section B1, Page B-1
>This section should probably make it clear that reserved _values_ (as
>distinguished from reserved bits or fields earlier on the page) _will_
>(and should) have receive checks applied to them.

This is a general comment regarding the SNA Formats document.  I have
passed it on to Gary Schultz.

Regards,
Gary Dudley